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Abstract 


The Extensible Authentication Protocol (EAP) provides support for multiple authentication 
methods. This document defines the EAP-NOOB authentication method for nimble out-of-band 
(OOB) authentication and key derivation. The EAP method is intended for bootstrapping all kinds 
of Internet-of-Things (IoT) devices that have no preconfigured authentication credentials. The 
method makes use of a user-assisted, one-directional, out-of-band (OOB) message between the 
peer device and authentication server to authenticate the in-band key exchange. The device must 
have a nonnetwork input or output interface, such as a display, microphone, speaker, or blinking 
light, that can send or receive dynamically generated messages of tens of bytes in length. 
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1. Introduction 


This document describes a method for registration, authentication, and key derivation for 
network-connected smart devices, such as consumer and enterprise appliances that are part of 
the Internet of Things (IoT). These devices may be off-the-shelf hardware that is sold and 
distributed without any prior registration or credential-provisioning process, or they may be 
recycled devices after a hard reset. Thus, the device registration in a server database, ownership 
of the device, and the authentication credentials for both network access and application-level 
security must all be established at the time of the device deployment. Furthermore, many such 
devices have only limited user interfaces that could be used for their configuration. Often, the 
user interfaces are limited to either only input (e.g.,a camera) or output (e.g., a display screen). 
The device configuration is made more challenging by the fact that the devices may exist in large 
numbers and may have to be deployed or reconfigured nimbly based on user needs. 


To summarize, devices may have the following characteristics: 


e no preestablished relation with the intended server or user, 
e no preprovisioned device identifier or authentication credentials, or 


e an input or output interface that may be capable of only one-directional out-of-band 
communication. 


Many proprietary out-of-band (OOB) configuration methods exist for specific IoT devices. The 
goal of this specification is to provide an open standard and a generic protocol for bootstrapping 
the security of network-connected appliances, such as displays, printers, speakers, and cameras. 
The security bootstrapping in this specification makes use of a user-assisted OOB channel. The 
device authentication relies on a user having physical access to the device, and the key exchange 
security is based on the assumption that attackers are not able to observe or modify the messages 
conveyed through the OOB channel. We followthe common approach taken in pairing protocols: 
performing a Diffie-Hellman key exchange over the insecure network and authenticating the 
established key with the help of the OOB channel in order to prevent impersonation attacks. 


The solution presented here is intended for devices that have either a nonnetwork input or output 
interface, such as a camera, microphone, display screen, speaker, or blinking Light Emitting 
Diode (LED) light, that is able to send or receive dynamically generated messages of tens of bytes 
in length. Naturally, this solution may not be appropriate for very small sensors or actuators that 
have no user interface at all or for devices that are inaccessible to the user. We also assume that 
the OOB channel is at least partly automated (e.g.,a camera scanning a bar code); thus, there is 
no need to absolutely minimize the length of the data transferred through the OOB channel. This 
differs, for example, from Bluetooth pairing [Bluetooth], where it is essential to minimize the 
length of the manually transferred or compared codes. The OOB messages in this specification 
are dynamically generated. Thus, we do not support static printed registration codes. One reason 
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for requiring dynamic OOB messages is that the receipt of the OOB message authorizes the server 
to take ownership of the device. Dynamic OOB messages are more secure than static printed 
codes, which could be leaked and later misused. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


In addition, this document frequently uses the following terms as they have been defined in 
[RFC5216]: 


authenticator 
The entity initiating EAP authentication. 


peer 
The entity that responds to the authenticator. In [IEEE-802.1X], this entity is known as the 
supplicant. (We use the terms peer, device, and peer device interchangeably.) 


server 
The entity that terminates the EAP authentication method with the peer. In the case where 
no backend authentication server is used, the EAP server is part of the authenticator. In the 
case where the authenticator operates in pass-through mode, the EAP server is located on 
the backend authentication server. 


3. EAP-NOOB Method 


This section defines the EAP-NOOB method. The protocol is a generalized version of the original 
idea presented by Sethi et al. [Sethi14]. 


3.1. Protocol Overview 


One EAP-NOOB method execution spans two or more EAP conversations, called Exchanges in this 
specification. Each Exchange consists of several EAP request-response pairs. At least two separate 
EAP conversations are needed to give the human user time to deliver the OOB message between 
them. 


The overall protocol starts with the Initial Exchange, which comprises four EAP request-response 
pairs. In the Initial Exchange, the server allocates an identifier to the peer, and the server and 
peer negotiate the protocol version and cryptosuite (i.e., cryptographic algorithm suite), exchange 
nonces, and perform an Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange. The 
user-assisted OOB Step then takes place. This step requires only one out-of-band message, either 
from the peer to the server or from the server to the peer. While waiting for the OOB Step action, 
the peer MAY probe the server by reconnecting to it with EAP-NOOB. If the OOB Step has already 
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taken place, the probe leads to the Completion Exchange, which completes the mutual 
authentication and key confirmation. On the other hand, if the OOB Step has not yet taken place, 
the probe leads to the Waiting Exchange, and the peer will perform another probe after a server- 
defined minimum waiting time. The Initial Exchange and Waiting Exchange always end in EAP- 
Failure, while the Completion Exchange may result in EAP-Success. Once the peer and server have 
performed a successful Completion Exchange, both endpoints store the created association in 
persistent storage, and the OOB Step is not repeated. Thereafter, creation of new temporal keys, 
ECDHE rekeying, and updates of cryptographic algorithms can be achieved with the Reconnect 
Exchange. 


OOB Output/Initial Exchange/ 
Waiting Exchange 


.------------------ : Initial .------------------ : 
| | Exchange | | 
->| Unregistered (0) |---------------- >|Waiting for 00B(1) | 
l (ephemeral) l l (ephemeral) l 
| | | | 
| | Š 
User Reset Completion | | 
Exchange | OOB OOB 
<------- : .------------------------- É Input Reject/ 
| | | Initial 
| | | Exchange 
| v v | 
| | Exchange | | 
| Registered (4) |<---------------- | OOB Received (2) | 
l (persistent) l l (ephemeral) l 
| | | 


| 
Mobility/ l 


Timeout/ Reconnect 
Failure Exchange 
| | 
v | 


| 
| 
| 
S 
| 
| 
| 
| 
| | 
| .------------------ > Completion .------------------ ; 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


| 

| Reconnecting (3) 
l (persistent) 
| 


Figure 1: EAP-NOOB Server-Peer Association State Machine 


Figure 1 shows the association state machine, which is the same for the server and for the peer. 
(For readability, only the main state transitions are shown. The complete table of transitions can 
be found in Appendix A.) When the peer initiates the EAP-NOOB method, the server chooses the 
ensuing message exchange based on the combination of the server and peer states. The EAP 
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server and peer are initially in the Unregistered (0) state, in which no state information needs to 
be stored. Before a successful Completion Exchange, the server-peer association state is 
ephemeral in both the server and peer (ephemeral states 0..2), and a timeout or error may cause 
one or both endpoints to go back to the Unregistered (0) state so that the Initial Exchange is 
repeated. After the Completion Exchange has resulted in EAP-Success, the association state 
becomes persistent (persistent states 3..4). Only user reset or memory failure can cause the return 
of the server or the peer from the persistent states to the ephemeral states and to the Initial 
Exchange. 


The server MUST NOT repeat a successful OOB Step with the same peer except if the association 
with the peer is explicitly reset by the user or lost due to failure of the persistent storage in the 
server. More specifically, once the association has entered the Registered (4) state, the server 
MUST NOT delete the association or go back to the ephemeral states 0..2 without explicit user 
approval. Similarly, the peer MUST NOT repeat the OOB Step unless the user explicitly deletes the 
association with the server from the peer or resets the peer to the Unregistered (0) state. The 
server and peer MAY implement user reset of the association by deleting the state data from that 
endpoint. If an endpoint continues to store data about the association after the user reset, its 
behavior MUST be equivalent to having deleted the association data. 


It can happen that the peer accidentally (or through user reset) loses its persistent state and 
reconnects to the server without a previously allocated peer identifier. In that case, the server 
MUST treat the peer as a new peer. The server MAY use auxiliary information, suchas the PeerInfo 
field received in the Initial Exchange, to detect multiple associations with the same peer. 
However, it MUST NOT delete or merge redundant associations without user or application 
approval because EAP-NOOB internally has no secure way of verifying that the two peers are the 
same physical device. Similarly, the server might lose the association state because of a memory 
failure or user reset. In that case, the only way to recover is that the user also resets the peer. 


A special feature of the EAP-NOOB method is that the server is not assumed to have any a priori 
knowledge of the peer. Therefore, the peer initially uses the generic identity string "noob@eap- 
noob.arpa" as its Network Access Identifier (NAI). The server then allocates a server-specific 
identifier to the peer. The generic NAI serves two purposes: firstly, it tells the server that the peer 
supports and expects the EAP-NOOB method; secondly, it allows routing of the EAP-NOOB sessions 
to a specific authentication server in an Authentication, Authorization, and Accounting (AAA) 
architecture. 


EAP-NOOB is an unusual EAP method in that the peer has to have multiple EAP conversations 
with the server before it can receive EAP-Success. The reason is that, while EAP allows delays 
between the request-response pairs, e.g., for repeated password entry, the user delays in OOB 
authentication can be much longer than in password trials. Moreover, EAP-NOOB supports peers 
with no input capability in the user interface (e.g., LED light bulbs). Since users cannot initiate the 
protocol in these devices, the devices have to perform the Initial Exchange opportunistically and 
hope for the OOB Step to take place within a timeout period (NoobTimeout), which is why the 
timeout needs to be several minutes rather than seconds. To support such high-latency OOB 
channels, the peer and server perform the Initial Exchange in one EAP conversation, then allow 
time for the OOB message to be delivered, and later perform the Waiting Exchange and 
Completion Exchange in different EAP conversations. 
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3.2. Protocol Messages and Sequences 


This section defines the EAP-NOOB exchanges, which correspond to EAP conversations. The 
exchanges start with a common handshake, which determines the type of the following 
exchange. The common handshake messages and the subsequent messages for each exchange 
type are listed in the diagrams below. The diagrams also specify the data fields present in each 
message. Each exchange comprises multiple EAP request-response pairs and ends in either EAP- 
Failure, indicating that authentication is not (yet) successful, or in EAP-Success. 


3.2.1. Common Handshake in All EAP-NOOB Exchanges 


All EAP-NOOB exchanges start with common handshake messages. The handshake begins with 
the identity request and response that are common to all EAP methods. Their purpose is to enable 
the AAA architecture to route the EAP conversation to the EAP server and to enable the EAP server 
to select the EAP method. The handshake then continues with one EAP-NOOB request-response 
pair in which the server discovers the peer identifier used in EAP-NOOB and the peer state. 


In more detail, each EAP-NOOB exchange begins with the authenticator sending an EAP-Request/ 
Identity packet to the peer. From this point on, the EAP conversation occurs between the server 
and the peer, and the authenticator acts as a pass-through device. The peer responds to the 
authenticator with an EAP-Response/Identity packet, which contains the Network Access 
Identifier (NAI). The authenticator, acting as a pass-through device, forwards this response and 
the following EAP conversation between the peer and the AAA architecture. The AAA architecture 
routes the conversation to a specific AAA server (called "EAP server" or simply "server" in this 
specification) based on the realm part of the NAI. The server selects the EAP-NOOB method based 
on the user part of the NAI, as defined in Section 3.3.1. 


After receiving the EAP-Response/Identity message, the server sends the first EAP-NOOB request 
(Type=1) to the peer, which responds with the peer identifier (PeerId) and state (PeerState) in the 
range 0..3. However, the peer SHOULD omit the Peerld from the response (Type=1) when 
PeerState=0. The server then chooses the EAP-NOOB exchange, i.e., the ensuing message sequence, 
as explained below. The peer recognizes the exchange based on the message type field (Type) of 
the next EAP-NOOB request received from the server. 


The server MUST determine the exchange type based on the combination of the peer and server 
states as follows (also summarized in Table 14). If either the peer or server is in the Unregistered 
(0) state and the other is in one of the ephemeral states (0..2), the server chooses the Initial 
Exchange. If either the peer or server is in the OOB Received (2) state and the other is either in the 
Waiting for OOB (1) or OOB Received (2) state, the OOB Step has taken place and the server 
chooses the Completion Exchange. If both the server and peer are in the Waiting for OOB (1) state, 
the server chooses the Waiting Exchange. If the peer is in the Reconnecting (3) state and the 
server is in the Registered (4) or Reconnecting (3) state, the server chooses the Reconnect 
Exchange. All other state combinations are error situations where user action is required, and the 
server SHOULD indicate such errors to the peer with the error code 2002 (see Section 3.6.3). Note 
also that the peer MUST NOT initiate EAP-NOOB when the peer is in the Registered (4 state. 
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EAP Peer Authenticator EAP Server 
| | | 
| <----------- EAP-Request/Identity -| 
| 
| 
| 


| 

| 

SoS Sea EAP-Response/Identity -------------->| 
(NAI=noob@eap-noob.arpa) 

| 

| 


(Type=1) 


| 
| 
isa Sr EAP-Request/EAP-NOOB ---------------- 
| 
| 
| 


| 
| 
[Ree mamas EAP-Response/EAP-NOOB -------------- > | 
(Type=1, [PeerId], PeerState=1 ) 
| 
| 


| continuing with exchange-specific messages... 
Figure 2: Common Handshake in All EAP-NOOB Exchanges 


3.2.2. Initial Exchange 


The Initial Exchange comprises the common handshake and two further EAP-NOOB request- 
response pairs: one for version, cryptosuite, and parameter negotiation and the other for the 
ECDHE key exchange. The first EAP-NOOB request (Type=2) from the server contains a newly 
allocated Peerld for the peer and an optional NewNAI for assigning a new NAI to the peer. The 
server allocates a new Peerld in the Initial Exchange regardless of any old Peerld received in the 
previous response (Type=1). The server also sends in the request a list of the protocol versions 
(Vers) and cryptosuites (Cryptosuites) it supports, an indicator of the OOB channel directions it 
supports (Dirs), and a ServerInfo object. The peer chooses one of the versions and cryptosuites. 
The peer sends a response (Type=2) with the selected protocol version (Verp), the received Peerld, 
the selected cryptosuite (Cryptosuitep), an indicator of the OOB channel direction(s) selected by 
the peer (Dirp), and a PeerInfo object. In the second EAP-NOOB request and response (Type=3), 
the server and peer exchange the public components of their ECDHE keys and nonces (PKs, Ns, 
PKp, and Np). The ECDHE keys MUST be based on the negotiated cryptosuite, i.e., Cryptosuitep. The 
Initial Exchange always ends with EAP-Failure from the server because the authentication cannot 
yet be completed. 
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EAP Peer EAP Server 
| ...continuing from common handshake 


| 

[ee alt EAP-Request/EAP-NOOB ---------------- 
(Type=2, Vers, PeerlId, [NewNAT], 

l Cryptosuites, Dirs, ServerInfo) 
| 
| 


(Type=2,Verp, PeerId, Cryptosuitep, 


| 
| 
[e EAP-Response/EAP-NOOB -------------- : 
Dirp, PeerInfo) | 

| 


(Type=3, PeerId, PKs, Ns, [SleepTime] ) 


| 
| 
| 
[emn EAP-Request/EAP-NOOB ---------------- 
| 
| 
| 


| 
| 
[Reese EAP-Response/EAP-NOOB -------------- > | 
(Type=3, PeerId, PKp, Np) l 
| 
| 


Figure 3: Initial Exchange 


At the conclusion of the Initial Exchange, both the server and the peer move to the Waiting for 
OOB (1) state. 


3.2.3. OOB Step 


The OOB Step, labeled as OOB Output and OOB Input in Figure 1, takes place after the Initial 
Exchange. Depending on the negotiated OOB channel direction, the peer or the server outputs the 
OOB message as shown in Figures 4 or 5, respectively. The data fields are the Peerld, the secret 
nonce Noob, and the cryptographic fingerprint Hoob. The contents of the data fields are defined 
in Section 3.3.2. The OOB message is delivered to the other endpoint via a user-assisted OOB 
channel. 


For brevity, we will use the terms OOB sender and OOB receiver in addition to the already familiar 
EAP server and EAP peer. If the OOB message is sent in the server-to-peer direction, the OOB 
sender is the server and the OOB receiver is the peer. On the other hand, if the OOB message is 
sent in the peer-to-server direction, the OOB sender is the peer and the OOB receiver is the server. 


EAP Peer EAP Server 


l (PeerId, Noob, Hoob) 


Figure 4: OOB Step, from Peer to EAP Server 
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EAP Peer EAP Server 


l (PeerId, Noob, Hoob) 
Figure 5: OOB Step, from EAP Server to Peer 


The OOB receiver MUST compare the received value of the fingerprint Hoob (see Section 3.3.2) 
with a value that it computed locally for the PeerID received. This integrity check ensures that the 
endpoints agree on contents of the Initial Exchange. If the values are equal, the receiver moves to 
the OOB Received (2) state. Otherwise, the receiver MUST reject the OOB message. For usability 
reasons, the OOB receiver SHOULD indicate the acceptance or rejection of the OOB message to the 
user. The receiver SHOULD reject invalid OOB messages without changing its state in the 
association state machine until an application-specific number of invalid messages (OobRetries) 
has been reached; after which, the receiver SHOULD consider it an error and go back to the 
Unregistered (0) state. 


The server or peer MAY send multiple OOB messages with different Noob values while in the 
Waiting for OOB (1) state. The OOB sender SHOULD remember the Noob values until they expire 
and accept any one of them in the following Completion Exchange. The Noob values sent by the 
server expire after an application-dependent timeout (NoobTimeout), and the server MUST NOT 
accept Noob values older than that in the Completion Exchange. The RECOMMENDED value for 
NoobTimeout is 3600 seconds if there are no application-specific reasons for making it shorter or 
longer. The Noob values sent by the peer expire, as defined in Section 3.2.5. 


The OOB receiver does not accept further OOB messages after it has accepted one and moved to 
the OOB Received (2) state. However, the receiver MAY buffer redundant OOB messages in case an 
OOB message expiry or similar error detected in the Completion Exchange causes it to return to 
the Waiting for OOB (1) state. It is RECOMMENDED that the OOB receiver notifies the user about 
redundant OOB messages, but it MAY instead discard them silently. 


The sender will typically generate a new Noob, and therefore a new OOB message, at constant 
time intervals (NoobInterval). The RECOMMENDED interval is 


NoobInterval = NoobTimeout / 2 


in which case, the receiver of the OOB will at any given time accept either of the two latest Noob 
values. However, the timing of the Noob generation may also be based on user interaction or on 
implementation considerations. 


Even though not recommended (see Section 3.3), this specification allows both directions to be 
negotiated (Dirp=3) for the OOB channel. In that case, both sides SHOULD output the OOB 
message, and it is up to the user to deliver at least one of them. 


The details of the OOB channel implementation including the message encoding are defined by 
the application. Appendix D gives an example of how the OOB message can be encoded as a URL 
that may be embedded in a dynamic QR code or NFC (Near Field Communication) tag. 
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3.2.4. Completion Exchange 


After the Initial Exchange, if the OOB channel directions selected by the peer include the peer-to- 
server direction, the peer SHOULD initiate the EAP-NOOB method again after an applications- 
specific waiting time in order to probe for completion of the OOB Step. If the OOB channel 
directions selected by the peer include the server-to-peer direction and the peer receives the OOB 
message, it SHOULD initiate the EAP-NOOB method immediately. Depending on the combination 
of the peer and server states, the server continues with the Completion Exchange or Waiting 
Exchange (see Section 3.2.1 on how the server makes this decision). 


The Completion Exchange comprises the common handshake and one or two further EAP-NOOB 
request-response pairs. If the peer is in the Waiting for OOB (1) state, the OOB message has been 
sent in the peer-to-server direction. In that case, only one request-response pair (Type=6) takes 
place. In the request, the server sends the NooblId value (see Section 3.3.2), which the peer uses to 
identify the exact OOB message received by the server. On the other hand, if the peer is in the OOB 
Received (2) state, the direction of the OOB message is from server to peer. In this case, two 
request-response pairs (Type=5 and Type=6) are needed. The purpose of the first request-response 
pair (Type=5) is that it enables the server to discover Noobld, which identifies the exact OOB 
message received by the peer. The server returns the same Noobld to the peer in the latter request. 


In the last request-response pair (Type=6) of the Completion Exchange, the server and peer 
exchange message authentication codes. Both sides MUST compute the keys Kms and Kmp, as 
defined in Section 3.5, and the message authentication codes MACs and MACp, as defined in 
Section 3.3.2. Both sides MUST compare the received message authentication code witha locally 
computed value. If the peer finds that it has received the correct value of MACs and the server 
finds that it has received the correct value of MACp, the Completion Exchange ends in EAP- 
Success. Otherwise, the endpoint where the comparison fails indicates this with an error message 
(error code 4001, see Section 3.6.5), and the Completion Exchange ends in EAP-Failure. 


After the successful Completion Exchange, both the server and the peer move to the Registered (4) 
state. They also derive the output keying material and store the persistent EAP-NOOB association 
state, as defined in Sections 3.4 and 3.5. 


It is possible that the OOB message expires before it is received. In that case, the sender of the OOB 
message no longer recognizes the NooblId that it receives in the Completion Exchange. Another 
reason why the OOB sender might not recognize the Noobld is if the received OOB message was 
spoofed and contained an attacker-generated Noob value. The recipient of an unrecognized 
Noobld indicates this with an error message (error code 2003, see Section 3.6.1), and the 
Completion Exchange ends in EAP-Failure. The recipient of the error message 2003 moves back to 
the Waiting for OOB (1) state. This state transition is called OOB Reject in Figure 1 (even though it 
really is a specific type of failed Completion Exchange). On the other hand, the sender of the error 
message stays in its previous state. 
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Although it is not expected to occur in practice, poor user interface design could lead to two OOB 
messages delivered simultaneously, one from the peer to the server and the other from the server 
to the peer. The server detects this event in the beginning of the Completion Exchange by 
observing that both the server and peer are in the OOB Received (2) state. In that case, asa 
tiebreaker, the server MUST behave as if only the server-to-peer message had been delivered. 


EAP Peer EAP Server 
| ...continuing from common handshake 


| 

[Seo SS [ EAP-Request/EAP-NOOB ] ------------ 
l (Type=5,PeerId) 
| 
| 


| 
| 
[See eS [ EAP-Response/EAP-NOOB ] ---------- >| 
(Type=5, PeerId, NoobId) l 

| 

| 


| 
| 
|en EAP-Request/EAP-NOOB ---------------- 
l (Type=6, PeerId, NoobId, MACs) 

| 

| 


| 
| 
|o EREE EAP-Response/EAP-NOOB -------------- > | 
(Type=6, PeerId, MACp) l 
| 
| 


Figure 6: Completion Exchange 


3.2.5. Waiting Exchange 


As explained in Section 3.2.4, the peer SHOULD probe the server for completion of the OOB Step. 
When the combination of the peer and server states indicates that the OOB message has not yet 
been delivered, the server chooses the Waiting Exchange (see Section 3.2.1 on how the server 
makes this decision). The Waiting Exchange comprises the common handshake and one further 
request-response pair, and it always ends in EAP-Failure. 


In order to limit the rate at which peers probe the server, the server MAY send to the peer either in 
the Initial Exchange or in the Waiting Exchange a minimum time to wait before probing the 
server again. A peer that has not received an OOB message SHOULD wait at least the server- 
specified minimum waiting time in seconds (SleepTime) before initiating EAP again with the 
same server. The peer uses the latest SleepTime value that it has received in or after the Initial 
Exchange. If the server has not sent any SleepTime value, the peer MUST wait for an application- 
specified minimum time (SleepTimeDefault). 
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After the Waiting Exchange, the peer MUST discard (from its local ephemeral storage) Noob values 
that it has sent to the server in OOB messages that are older than the application-defined timeout 
NoobTimeout (see Section 3.2.3). The peer SHOULD discard such expired Noob values even if the 
probing failed because of, e.g., failure to connect to the EAP server or an incorrect message 
authentication code. The timeout of peer-generated Noob values is defined like this in order to 
allow the peer to probe the server once after it has waited for the server-specified SleepTime. 


If the server and peer have negotiated to use only the server-to-peer direction for the OOB 
channel (Dirp=2), the peer SHOULD nevertheless probe the server. The purpose of this is to keep 
the server informed about the peers that are still waiting for OOB messages. The server MAY set 
SleepTime to a high number (e.g., 3600) to prevent the peer from probing the server frequently. 


EAP Peer EAP Server 
| ...continuing from common handshake 


| 

[em EAP-Request/EAP-NOOB ---------------- 
(Type=4, Peerld, [SleepTime] ) 
| 
| 


| 
| 
[m EAP-Response/EAP-NOOB -------------- > | 
(Type=4, PeerId) l 
| 
| 


Figure 7: Waiting Exchange 


3.3. Protocol Data Fields 
This section defines the various identifiers and data fields used in the EAP-NOOB method. 


3.3.1. Peer Identifier and NAI 


The server allocates a new peer identifier (Peerld) for the peer in the Initial Exchange. The peer 
identifier MUST follow the syntax of the utf8-username specified in [RFC7542]. The server MUST 
generate the identifiers in such a way that they do not repeat and cannot be guessed by the peer 
or third parties before the server sends them to the peer in the Initial Exchange. One way to 
generate the identifiers is to choose a random 16-byte identifier and to base64url encode it 
without padding [RFC4648] into a 22-character ASCII string. Another way to generate the 
identifiers is to choose a random 22-character alphanumeric ASCII string. It is RECOMMENDED to 
not use identifiers longer than this because they result in longer OOB messages. 


The peer uses the allocated Peerld to identify itself to the server in the subsequent exchanges. The 
peer MUST copy the Peerld byte by byte from the message where it was allocated, and the server 
MUST perform a byte-by-byte comparison between the received and the previously allocated 
PeerID. The peer sets the PeerId value in response type 1 as follows. As stated in Section 3.2.1, when 
the peer is in the Unregistered (0) state, it SHOULD omit the PeerId from response type 1. When the 
peer is in one of the states 1..2, it MUST use the Peerld that the server assigned to it in the latest 
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Initial Exchange. When the peer is in one of the persistent states 3..4, it MUST use the Peerld from 
its persistent EAP-NOOB association. (The Peerld is written to the association when the peer 
moves to the Registered (4) state after a Completion Exchange.) 


The default NAI for the peer is "noob@eap-noob.arpa". The peer implementation MAY allow the 
user or application to configure a different NAI, which overrides the default NAI. Furthermore, the 
server MAY assign a new NAI to the peer in the Initial Exchange or Reconnect Exchange in the 
NewNAI field of request types 2 and 7 to override any previous NAI value. When the peer is in the 
Unregistered (0) state, or when the peer is in one of the states 1..2 and the server did not senda 
NewNaAI in the latest Initial Exchange, the peer MUST use the configured NAI or, if it does not exist, 
the default NAI. When the peer is in one of the states 1..2 and the server sent a NewNAI in the 
latest Initial Exchange, the peer MUST use this server-assigned NAI. When the peer moves to the 
Registered (4) state after the Completion Exchange, it writes to the persistent EAP-NOOB 
association the same NAI value that it used in the Completion Exchange. When the peer is in the 
Reconnecting (3) or Registered (4) state, it MUST use the NAI from its persistent EAP-NOOB 
association. When the server sends NewNAI in the Reconnect Exchange, the peer writes its value 
to the persistent EAP-NOOB association when it moves from the Reconnecting (3) state to the 
Registered (4) state. All the NAI values MUST follow the syntax specified in [RFC7542]. 


The purpose of the server-assigned NAI is to enable more flexible routing of the EAP sessions over 
the AAA infrastructure, including roaming scenarios (see Appendix C). Moreover, some 
authenticators or AAA servers use the realm part of the assigned NAI to determine peer-specific 
connection parameters, such as isolating the peer to a specific VLAN. On the other hand, the user- 
or application-configured NAI enables registration of new devices while roaming. It also enables 
manufacturers to set up their own AAA servers for bootstrapping of new peer devices. 


The peer's PeerId and server-assigned NAI are ephemeral until a successful Completion Exchange 
takes place. Thereafter, the values become parts of the persistent EAP-NOOB association until the 
user resets the peer and server or until a new NAT is assigned in the Reconnect Exchange. 


3.3.2. Message Data Fields 


Table 1 defines the data fields in the protocol messages. The in-band messages are formatted as 
JSON objects [RFC8259] in UTF-8 encoding. The JSON member names are in the left-hand column 
of the table. 


Data Field Description 


Vers, Verp EAP-NOOB protocol versions supported by the EAP server and the protocol 
version chosen by the peer. Vers is a JSON array of unsigned integers, and 
Verp is an unsigned integer. Example values are "[1]" and "1", respectively. 


Peerld Peer identifier, as defined in Section 3.3.1. 


NAI, NewNAI Peer NAI and server-assigned new peer NAI, as defined in Section 3.3.1. 
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Data Field 


Type 


PeerState 


PKs, PKp 


Cryptosuites, 
Cryptosuitep 


Dirs, Dirp 


Dir 


Ns, Np 


ServerInfo 


PeerInfo 
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Description 


EAP-NOOB message type. The type is an integer in the range 0..9. EAP-NOOB 
requests and the corresponding responses share the same type value. 


Peer state is an integer in the range 0..4 (see Figure 1). However, only values 
0..3 are ever sent in the protocol messages. 


The public components of the ECDHE keys of the server and peer. PKs and 
PKp are sent in the JSON Web Key (JWK) format [RFC7517]. The detailed 
format of the JWK object is defined by the cryptosuite. 


The identifiers of cryptosuites supported by the server and of the cryptosuite 
selected by the peer. The server-supported cryptosuites in Cryptosuites are 
formatted as a JSON array of the identifier integers. The server MUST send a 
nonempty array with no repeating elements, ordered by decreasing priority. 
The peer MUST respond with exactly one suite in the Cryptosuitep value, 
formatted as an identifier integer. Mandatory-to-implement cryptosuites 
and the registration procedure for new cryptosuites are specified in Section 
5.1. Example values are "[1]" and "1", respectively. 


An integer indicating the OOB channel directions supported by the server 
and the directions selected by the peer. The possible values are 1=peer-to- 
server, 2=server-to-peer, and 3=both directions. 


The actual direction of the OOB message (1=peer-to-server, 2=server-to-peer). 
This value is not sent over any communication channel, but it is included in 
the computation of the cryptographic fingerprint Hoob. 


32-byte nonces for the Initial Exchange. 


This field contains information about the server to be passed from the EAP 
method to the application layer in the peer. The information is specific to the 
application or to the OOB channel, and it is encoded as a JSON object of at 
most 500 bytes. It could include, for example, the access-network name and 
server name, a Uniform Resource Locator (URL) [RFC3986], or some other 
information that helps the user deliver the OOB message to the server 
through the out-of-band channel. 


This field contains information about the peer to be passed from the EAP 
method to the application layer in the server. The information is specific to 
the application or to the OOB channel, and it is encoded as a JSON object of 
at most 500 bytes. It could include, for example, the peer brand, model, and 
serial number, which help the user distinguish between devices and deliver 
the OOB message to the correct peer through the out-of-band channel. 
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Data Field 


SleepTime 


Noob 


Hoob 


NooblId 


MACs, MACp 


Ns2, Np2 


KeyingMode 


PKs2, PKp2 


MACs2, 
MACp2 


ErrorCode 


ErrorInfo 
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Description 


The number of seconds for which the peer MUST NOT start a new execution 
of the EAP-NOOB method with the authenticator, unless the peer receives the 
OOB message or the sending is triggered by an application-specific user 
action. The server can use this field to limit the rate at which peers probe it. 
SleepTime is an unsigned integer in the range 0..3600. 


16-byte secret nonce sent through the OOB channel and used for the session 
key derivation. The endpoint that received the OOB message uses this secret 
in the Completion Exchange to authenticate the exchanged key to the 
endpoint that sent the OOB message. 


16-byte cryptographic fingerprint (i.e., hash value) computed from all the 
parameters exchanged in the Initial Exchange and in the OOB message. 
Receiving this fingerprint over the OOB channel guarantees the integrity of 
the key exchange and parameter negotiation. Hence, it authenticates the 
exchanged key to the endpoint that receives the OOB message. 


16-byte identifier for the OOB message, computed with a one-way function 
from the nonce Noob in the message. 


Message authentication codes (HMAC) for mutual authentication, key 
confirmation, and integrity check on the exchanged information. The input 
to the HMAC is defined below, and the key for the HMAC is defined in Section 
3.5. 


32-byte nonces for the Reconnect Exchange. 


Integer indicating the key derivation method. 0 in the Completion Exchange, 
and 1..3 in the Reconnect Exchange. 


The public components of the ECDHE keys of the server and peer for the 
Reconnect Exchange. PKp2 and PKs2 are sent in the JSON Web Key (JWK) 
format [RFC7517]. The detailed format of the JWK object is defined by the 
cryptosuite. 


Message authentication codes (HMAC) for mutual authentication, key 
confirmation, and integrity check on the Reconnect Exchange. The input to 
the HMAC is defined below, and the key for the HMAC is defined in Section 
3.5. 


Integer indicating an error condition. Defined in Section 5.3. 


Textual error message for logging and debugging purposes. A UTF-8 string of 
at most 500 bytes. 


Table 1: Message Data Fields 
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It is RECOMMENDED for servers to support both OOB channel directions (Dirs=3) unless the type of 
the OOB channel limits them to one direction (Dirs=1 or Dirs=2). On the other hand, it is 
RECOMMENDED that the peer selects only one direction (Dirp=1 or Dirp=2) even when both 
directions (Dirp=3) would be technically possible. The reason is that, if value 3 is negotiated, the 
user may be presented with two OOB messages, one for each direction, even though only one of 
them needs to be delivered. This can be confusing to the user. Nevertheless, the EAP-NOOB 
protocol is designed to also cope with the value 3; in which case, it uses the first delivered OOB 
message. In the unlikely case of simultaneously delivered OOB messages, the protocol prioritizes 
the server-to-peer direction. 


The nonces in the in-band messages (Ns, Np, Ns2, Np2) are 32-byte fresh random byte strings, and 
the secret nonce Noob is a 16-byte fresh random byte string. All the nonces are generated by the 
endpoint that sends the message. 


The fingerprint Hoob and the identifier NoobId are computed with the cryptographic hash 
function H, which is specified in the negotiated cryptosuite and truncated to the 16 leftmost bytes 
of the output. The message authentication codes (MACs, MACp, MACs2, MACp2) are computed 
with the function HMAC, which is the hashed message authentication code [RFC2104] based on 
the cryptographic hash function H and truncated to the 32 leftmost bytes of the output. 


The inputs to the hash function for computing the fingerprint Hoob and to the HMAC for 
computing MACs, MACp, MACs2, and MACp2 are JSON arrays containing a fixed number (17) of 
elements. The array elements MUST be copied to the array verbatim from the sent and received 
in-band messages. When the element is a JSON object, its members MUST NOT be reordered or 
reencoded. White space MUST NOT be added anywhere in the JSON structure. Implementers 
should check that their JSON library copies the elements as UTF-8 strings, does not modify them in 
any way, and does not add white space to the HMAC input. 


The inputs for computing the fingerprint and message authentication codes are the following: 
Hoob = H(Dir, Vers, Verp, PeerId,Cryptosuites,Dirs,ServerInfo, 
Cryptosuitep, Dirp, NAI, PeerInfo,@,PKs,Ns,PKp,Np,Noob). 
NoobId = H("NoobId",Noob). 


MACs = HMAC(Kms; 2,Vers,Verp, PeerId,Cryptosuites, Dirs, ServerInfo, 
Cryptosuitep, Dirp, NAI, PeerInfo,@,PKs,Ns,PKp,Np,Noob). 


MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites, Dirs, ServerInfo, 
Cryptosuitep, Dirp, NAI, PeerInfo,@,PKs,Ns,PKp,Np,Noob). 


MACs2 = HMAC(Kms2; 2,Vers,Verp,Peerld,Cryptosuites,"",[ServerInfo], 
Cryptosuitep, "",NAI, [PeerInfo],KeyingMode, [PKs2],Ns2,[PKp2],Np2,"") 


MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerlId,Cryptosuites,"",[ServerInfo], 
Cryptosuitep, "",NAI, [PeerInfo],KeyingMode, [PKs2],Ns2,[PKp2],Np2,"") 
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The inputs denoted with "" above are not present, and the values in brackets [] are optional. Both 
kinds of missing input values are represented by empty strings "" in the HMAC input (JSON array). 
The NAI included in the inputs is the NAI value that will be in the persistent EAP-NOOB association 
if the Completion Exchange or Reconnect Exchange succeeds. In the Completion Exchange, the 
NAI is the NewNAI value assigned by the server in the preceding Initial Exchange or, if no NewNAI 
was sent, the NAI used by the client in the Initial Exchange. In the Reconnect Exchange, the NAI is 
the NewNAI value assigned by the server in the same Reconnect Exchange or, if no NewNAI was 
sent, the unchanged NAI from the persistent EAP-NOOB association. Each of the values in 
brackets for the computation of Macs2 and Macp2 MUST be included if it was sent or received in 
the same Reconnect Exchange; otherwise, the value is replaced by an empty string "". 

The parameter Dir indicates the direction in which the OOB message containing the Noob value is 
being sent (1=peer-to-server, 2=server-to-peer). This field is included in the Hoob input to prevent 
the user from accidentally delivering the OOB message back to its originator in the rare cases 
where both OOB directions have been negotiated. The keys (Kms, Kmp, Kms2, and Kmp2) for the 
HMACs are defined in Section 3.5. 


The nonces (Ns, Np, Ns2, Np2, and Noob) and the hash value (NoobId) MUST be base64url encoded 
[RFC4648] when they are used as input to the cryptographic functions H or HMAC. These values 
and the message authentication codes (MACs, MACp, MACs2, and MACp2) MUST also be base64url 
encoded when they are sent as JSON strings in the in-band messages. The values Noob and Hoob 
in the OOB channel MAY be base64url encoded if that is appropriate for the application and the 
OOB channel. All base64url encoding is done without padding. The base64url-encoded values will 
naturally consume more space than the number of bytes specified above (e.g., a 22-character 
string for a 16-byte nonce and a 43-character string for a 32-byte nonce or message 
authentication code). In the key derivation in Section 3.5, on the other hand, the unencoded 
nonces (raw bytes) are used as input to the key derivation function. 


The ServerInfo and PeerInfo are JSON objects with UTF-8 encoding. The length of either encoded 
object as a byte array MUST NOT exceed 500 bytes. The format and semantics of these objects 
MUST be defined by the application that uses the EAP-NOOB method. 


3.4. Fast Reconnect and Rekeying 


EAP-NOOB implements fast reconnect ([RFC3748], Section 7.2.1), which avoids repeated use of the 
user-assisted OOB channel. 


The rekeying and the Reconnect Exchange may be needed for several reasons. New EAP output 
values Main Session Key (MSK) and Extended Main Session Key (EMSK) may be needed because 
of mobility or timeout of session keys. Software or hardware failure or user action may also cause 
the authenticator, EAP server, or peer to lose its nonpersistent state data. The failure would 
typically be detected by the peer or authenticator when session keys are no longer accepted by 
the other endpoint. Changes in the supported cryptosuites in the EAP server or peer may also 
cause the need for a new key exchange. When the EAP server or peer detects any one of these 
events, it MUST change from the Registered (4) state to the Reconnecting (3) state. These state 
transitions are labeled Mobility/Timeout/Failure in Figure 1. The EAP-NOOB method will then 
perform the Reconnect Exchange the next time when EAP is triggered. 
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3.4.1. Persistent EAP-NOOB Association 


December 2021 


To enable rekeying, the EAP server and peer store the session state in persistent memory after a 
successful Completion Exchange. This state data, called "persistent EAP-NOOB association", MUST 
include at least the data fields shown in Table 2. They are used for identifying and authenticating 
the peer in the Reconnect Exchange. When a persistent EAP-NOOB association exists, the EAP 
server and peer are in the Registered (4) state or Reconnecting (3) state, as shown in Figure 1. 


Data Field 


Peerld 


Verp 
Cryptosuitep 


CryptosuitepPrev (at 
peer only) 


NAI 


Kz 


KzPrev (at peer only) 


Value 


Peer identifier allocated by server 


Negotiated protocol version 
Negotiated cryptosuite 


Previous cryptosuite 


NAI assigned by the server or configured 
by the user or the default NAI "noob@eap- 
noob.arpa" 


Persistent key material 


Previous Kz value 


Table 2: Persistent EAP-NOOB Association 


3.4.2. Reconnect Exchange 


Type 


UTF-8 string (typically 
22 ASCII characters) 


integer 
integer 


integer 


UTF-8 string 


32 bytes 


32 bytes 


The server chooses the Reconnect Exchange when both the peer and the server are in a persistent 
state and fast reconnection is needed (see Section 3.2.1 for details). 
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The Reconnect Exchange comprises the common handshake and three further EAP-NOOB 
request-response pairs: one for cryptosuite and parameter negotiation, another for the nonce 
and ECDHE key exchange, and the last one for exchanging message authentication codes. In the 
first request and response (Type=7), the server and peer negotiate a protocol version and 
cryptosuite in the same way as in the Initial Exchange. The server SHOULD NOT offer and the peer 
MUST NOT accept protocol versions or cryptosuites that it knows to be weaker than the one 
currently in the Cryptosuitep field of the persistent EAP-NOOB association. The server SHOULD 
NOT needlessly change the cryptosuites it offers to the same peer because peer devices may have 
limited ability to update their persistent storage. However, if the peer has different values in the 
Cryptosuitep and CryptosuitepPrev fields, it SHOULD also accept offers that are not weaker than 
CryptosuitepPrev. Note that Cryptosuitep and CryptosuitePrev from the persistent EAP-NOOB 
association are only used to support the negotiation as described above; all actual cryptographic 
operations use the newly negotiated cryptosuite. The request and response (Type=7) MAY 
additionally contain PeerInfo and ServerInfo objects. 


The server then determines the KeyingMode (defined in Section 3.5) based on changes in the 
negotiated cryptosuite and whether it desires to achieve forward secrecy or not. The server 
SHOULD only select KeyingMode 3 when the negotiated cryptosuite differs from the Cryptosuitep 
in the server's persistent EAP-NOOB association, although it is technically possible to select this 
value without changing the cryptosuite. In the second request and response (Type=8), the server 
informs the peer about the KeyingMode and the server and peer exchange nonces (Ns2, Np2). 
When KeyingMode is 2 or 3 (rekeying with ECDHE), they also exchange public components of 
ECDHE keys (PKs2, PKp2). The server ECDHE key MUST be fresh, i.e., not previously used with the 
same peer, and the peer ECDHE key SHOULD be fresh, i.e., not previously used. 


In the third and final request and response (Type=9), the server and peer exchange message 
authentication codes. Both sides MUST compute the keys Kms2 and Kmpz2, as defined in Section 
3.5, and the message authentication codes MACs2 and MACp2, as defined in Section 3.3.2. Both 
sides MUST compare the received message authentication code witha locally computed value. 


The rules by which the peer compares the received MACs2 are nontrivial because, in addition to 
authenticating the current exchange, MACs2 may confirm the success or failure of a recent 
cryptosuite upgrade. The peer processes the final request (Type=9) as follows: 


1. The peer first compares the received MACs2 value with one it computed using the Kz stored in 
the persistent EAP-NOOB association. If the received and computed values match, the peer 
deletes any data stored in the CryptosuitepPrev and KzPrev fields of the persistent EAP-NOOB 
association. It does this because the received MACs2 confirms that the peer and server share 
the same Cryptosuitep and Kz, and any previous values must no longer be accepted. 


2. On the other hand, if the peer finds that the received MACs2 value does not match the one it 
computed locally with Kz, the peer checks whether the KzPrev field in the persistent EAP- 
NOOB association stores a key. If it does, the peer repeats the key derivation (Section 3.5) and 
local MACs2 computation (Section 3.3.2) using KzPrev in place of kz. If this second computed 
MACs2 matches the received value, the match indicates synchronization failure caused by 
the loss of the last response (Type=9) in a previously attempted cryptosuite upgrade. In this 
case, the peer rolls back that upgrade by overwriting Cryptosuitep with CryptosuitepPrev and 
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Kz with KzPrev in the persistent EAP-NOOB association. It also clears the CryptosuitepPrev 
and KzPrev fields. 

3. If the received MACs2 matched one of the locally computed values, the peer proceeds to send 
the final response (Type=9). The peer also moves to the Registered (4) state. When 
KeyingMode is 1 or 2, the peer stops here. When KeyingMode is 3, the peer also updates the 
persistent EAP-NOOB association with the negotiated Cryptosuitep and the newly derived Kz 
value. To prepare for possible synchronization failure caused by the loss of the final response 
(Type=9) during cryptosuite upgrade, the peer copies the old Cryptosuitep and Kz values in the 
persistent EAP-NOOB association to the CryptosuitepPrev and KzPrev fields. 


4. Finally, if the peer finds that the received MACs2 does not match either of the two values that 
it computed locally (or one value if no KzPrev was stored), the peer sends an error message 
(error code 4001, see Section 3.6.5), which causes the Reconnect Exchange to end in EAP- 
Failure. 


The server rules for processing the final message are simpler than the peer rules because the 
server does not store previous keys and it never rolls back a cryptosuite upgrade. Upon receiving 
the final response (Type=9), the server compares the received value of MACp2 with one it 
computes locally. If the values match, the Reconnect Exchange ends in EAP-Success. When 
KeyingMode is 3, the server also updates Cryptosuitep and kz in the persistent EAP-NOOB 
association. On the other hand, if the server finds that the values do not match, it sends an error 
message (error code 4001), and the Reconnect Exchange ends in EAP-Failure. 


The endpoints MAY send updated NewNAI, ServerInfo, and PeerInfo objects in the Reconnect 
Exchange. When there is no update to the values, they SHOULD omit this information from the 
messages. If the NewNAI was sent, each side updates NAI in the persistent EAP-NOOB association 
when moving to the Registered (4 state. 
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EAP Peer EAP Server 
| ...continuing from common handshake 


| 

Ra EAP-Request/EAP-NOOB ---------------- 
| (Type=7, Vers, PeerId,Cryptosuites, 

[NewNAI], [ServerInfo] ) 
| 
| 


| 

| 

| 

[e EAP-Response/EAP-NOOB -------------- > | 
(Type=7, Verp, PeerlId, Cryptosuitep, [PeerInfo] ) | 

| 
| 


| 
| 
[n EAP-Request/EAP-NOOB ---------------- 
l (Type=8,PeerId,KeyingMode, [PKs2],Ns2) 

| 

| 


| 
| 
| eta lc td calcio EAP-Response/EAP-NOOB -------------- > | 
(Type=8, PeerlId, [PKp2],Np2) 

| 

| 


| 
| 
|<= EAP-Request/EAP-NOOB ---------------- 
l (Type=9, PeerId, MACs2) 

| 

| 


| 
| 
| Bees arian EAP-Response/EAP-NOOB -------------- > | 
(Type=9, PeerId, MACp2) l 
| 
| 


Figure 8: Reconnect Exchange 


3.4.3. User Reset 


As shown in the association state machine in Figure 1, the only specified way for the association 
to return from the Registered (4) state to the Unregistered (0) state is through user-initiated reset. 
After the reset, anew OOB message will be needed to establish a new association between the EAP 
server and peer. Typical situations in which the user reset is required are when the other side has 
accidentally lost the persistent EAP-NOOB association data or when the peer device is 
decommissioned. 


The server could detect that the peer is in the Registered or Reconnecting state, but the server 
itself is in one of the ephemeral states 0..2 (including situations where the server does not 
recognize the Peerld). In this case, effort should be made to recover the persistent server state, for 
example, from a backup storage -- especially if many peer devices are similarly affected. If that is 
not possible, the EAP server SHOULD log the error or notify an administrator. The only way to 
continue from sucha situation is by having the user reset the peer device. 


On the other hand, if the peer is in any of the ephemeral states 0..2, including the Unregistered 
state, the server will treat the peer as a new peer device and allocate a new Peerld to it. The 
PeerInfo can be used by the user as a clue to which physical device has lost its state. However, 
there is no secure way of matching the "new" peer with the old Peerld without repeating the OOB 
Step. This situation will be resolved when the user performs the OOB Step and thus identifies the 
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physical peer device. The server user interface MAY support situations where the "new" peer is 
actually a previously registered peer that has been reset by a user or otherwise lost its persistent 
data. In those cases, the user could choose to merge the new peer identity with the old one in the 
server. The alternative is to treat the device just like a new peer. 


3.5. Key Derivation 


EAP-NOOB derives the EAP output values MSK and EMSK and other secret keying material from 
the output of an Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) algorithm following the NIST 
specification [NIST-DH]. In NIST terminology, we use a C(2e, 0s, ECC CDH) scheme, i.e., two 
ephemeral keys and no static keys. In the Initial Exchange and Reconnect Exchange, the server 
and peer compute the ECDHE shared secret Z, as defined in Section 6.1.2 of the NIST specification 
[NIST-DH]. In the Completion Exchange and Reconnect Exchange, the server and peer compute 
the secret keying material from Z with the one-step key derivation function (KDF) defined in 
Section 5.8.2.1 of the NIST specification. The auxiliary function H is a hash function, and it is taken 
from the negotiated cryptosuite. 


KeyingMode Description 


0 Completion Exchange (always with ECDHE) 

1 Reconnect Exchange, rekeying without ECDHE 

2 Reconnect Exchange, rekeying with ECHDE, no change in cryptosuite 

3 Reconnect Exchange, rekeying with ECDHE, new cryptosuite negotiated 


Table 3: Keying Modes 


The key derivation has four different modes (KeyingMode), which are specified in Table 3. Table 4 
defines the inputs to KDF in each KeyingMode. 


In the Completion Exchange (KeyingMode=0), the input Z comes from the preceding Initial 
exchange. The KDF takes some additional inputs (FixedInfo), for which we use the concatenation 
format defined in Section 5.8.2.1.1 of the NIST specification [NIST-DH]. FixedInfo consists of the 
AlgorithmId, PartyUInfo, PartyVInfo, and SuppPrivInfo fields. The first three fields are fixed- 
length bit strings, and SuppPrivInfo is a variable-length string with a one-byte Datalength 
counter. AlgorithmId is the fixed-length, 8-byte ASCII string "EAP-NOOB". The other input values 
are the server and peer nonces. In the Completion Exchange, the inputs also include the secret 
nonce Noob from the OOB message. 


In the simplest form of the Reconnect Exchange (KeyingMode=1), fresh nonces are exchanged, 
but no ECDHE keys are sent. In this case, input Z to the KDF is replaced with the shared key Kz 
from the persistent EAP-NOOB association. The result is rekeying without the computational cost 
of the ECDHE exchange but also without forward secrecy. 
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When forward secrecy is desired in the Reconnect Exchange (KeyingMode=2 or KeyingMode=3), 
both nonces and ECDHE keys are exchanged. Input Z is the fresh shared secret from the ECDHE 
exchange with PKs2 and PKp2. The inputs also include the shared secret Kz from the persistent 
EAP-NOOB association. This binds the rekeying output to the previously authenticated keys. 


KeyingMode 


0 Completion 


1 Reconnect, rekeying without 


ECDHE 


2 or 3 Reconnect, rekeying, with 
ECDHE, same or new cryptosuite 


Table 4: Key Derivation Input 
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KDF input 
field 


Z 


AlgorithmId 
PartyUInfo 
PartyVInfo 
SuppPubInfo 
SuppPrivInfo 
Z 
AlgorithmId 
PartyUInfo 
PartyVInfo 
SuppPubInfo 
SuppPrivInfo 


Z 


AlgorithmId 
PartyUInfo 
PartyVInfo 
SuppPubInfo 


SuppPrivInfo 


Standards Track 


Value 


ECDHE shared secret 
from PKs and PKp 


"EAP-NOOB" 
Np 

Ns 

(not allowed) 
Noob 

Kz 
"EAP-NOOB" 
Np2 

Ns2 

(not allowed) 
(null) 


ECDHE shared secret 
from PKs2 and PKp2 


"EAP-NOOB" 
Np2 

Ns2 

(not allowed) 


Kz 


Length 
(bytes) 


variable 


32 


32 


32 


0 


variable 


32 


32 
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Table 5 defines how the output bytes of the KDF are used. In addition to the EAP output values 
MSK and EMSK, the server and peer derive another shared secret key AMSK (Application Main 
Session Key), which MAY be used for application-layer security. Further output bytes are used 
internally by EAP-NOOB for the message authentication keys (Kms, Kmp, Kms2, and Kmp2). 


The Completion Exchange (KeyingMode=0) produces the shared secret Kz, which the server and 
peer store in the persistent EAP-NOOB association. When a newcryptosuite is negotiated in the 
Reconnect Exchange (KeyingMode=3), it similarly produces a new kz. In that case, the server and 
peer update both the cryptosuite and Kz in the persistent EAP-NOOB association. Additionally, the 
peer stores the previous Cryptosuitep and Kz values in the CryptosuitepPrev and KzPrev fields of 
the persistent EAP-NOOB association. 


KeyingMode KDF output Used as Length 
bytes (bytes) 
0 Completion 0..63 MSK 64 
64..127 EMSK 64 
128..191 AMSK 64 
192..223 MethodId 32 
224..255 Kms 32 
256..287 Kmp 32 
288..319 Kz 32 
1 or 2 Reconnect, rekeying without ECDHE, or with 0..63 MSK 64 
ECDHE and unchanged cryptosuite 
64..127 EMSK 64 
128..191 AMSK 64 
192..223 MethodId 32 
224..255 Kms2 32 
256..287 Kmp2 32 
3 Reconnect, rekeying with ECDHE, new 0..63 MSK 64. 
cryptosuite 
64..127 EMSK 64 
128..191 AMSK 64 
192-223 MethodId 32 
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KeyingMode KDF output Used as Length 
bytes (bytes) 
224..255 Kms2 32 
256..287 Kmp2 32 
288..319 Kz 32 


Table 5: Key Derivation Output 


Finally, every EAP method must export a Server-Id, Peer-Id, and Session-Id [RFC5247]. In EAP- 
NOOB, the exported Peer-Id is the Peerld that the server has assigned to the peer. The exported 
Server-Id is a zero-length string (i.e., null string) because EAP-NOOB neither knows nor assigns 
any server identifier. The exported Session-Id is created by concatenating the one-byte Type-Code 
0x38 (decimal value 56) with the MethodId, which is obtained from the KDF output, as shown in 
Table 5. 


3.6. Error Handling 


Various error conditions in EAP-NOOB are handled by sending an error notification message 
(Type=0) instead of a next EAP request or response message. Both the EAP server and the peer 
may send the error notification, as shown in Figures 9 and 10. After sending or receiving an error 
notification, the server MUST send an EAP-Failure (as required by [RFC3748], Section 4.2). The 
notification MAY contain an ErrorInfo field, which is a UTF-8-encoded text string witha 
maximum length of 500 bytes. It is used for sending descriptive information about the error for 
logging and debugging purposes. 


EAP Peer EAP Server 


See eee EAP-Request/EAP-NOOB ---------------- 
(Type=0, [PeerId],ErrorCode, [ErrorInfo] ) 


Saon nonan EAR Farlure m ma 


Figure 9: Error Notification from Server to Peer 
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EAP Peer EAP Server 


Gerdes cate EAP-Response/EAP-NOOB -------------- > | 
(Type=0, [PeerId],ErrorCode, [ErrorInfo] ) 
| 
| 


Koon o Sas EAR Far UIs Ce 
| 


Figure 10: Error Notification from Peer to Server 


After the exchange fails due to an error notification, the server and peer set the association state 
as follows. In the Initial Exchange, both the sender and recipient of the error notification MUST 
set the association state to the Unregistered (0) state. In the Waiting Exchange and Completion 
Exchange, each side MUST remain in its old state as if the failed exchange had not taken place, 
with the exception that the recipient of error code 2003 processes it as specified in Section 3.2.4. In 
the Reconnect Exchange, both sides MUST set the association state to the Reconnecting (3) state. 


Errors that occur in the OOB channel are not explicitly notified in-band. 


3.6.1. Invalid Messages 


If the NAI structure is invalid, the server SHOULD send the error code 1001 to the peer. The 
recipient of an EAP-NOOB request or response SHOULD send the following error codes back to the 
sender: 1002 if it cannot parse the message as a JSON object or the top-level JSON object has 
missing or unrecognized members; 1003 if a data field has an invalid value, such as an integer out 
of range, and there is no more specific error code available; 1004 if the received message type was 
unexpected in the current state; 2004 if the PeerId has an unexpected value; 2003 if the NoobId is 
not recognized; and 1005 if the ECDHE key is invalid. 


3.6.2. Unwanted Peer 


The preferred way for the EAP server to rate limit EAP-NOOB connections from a peer is to use the 
SleepTime parameter in the Waiting Exchange. However, if the EAP server receives repeated EAP- 
NOOB connections from a peer that apparently should not connect to this server, the server MAY 
indicate that the connections are unwanted by sending the error code 2001. After receiving this 
error message, the peer MAY refrain from reconnecting to the same EAP server, and, if possible, 
both the EAP server and peer SHOULD indicate this error condition to the user or server 
administrator. However, in order to avoid persistent denial of service, peer devices that are 
unable to alert a user SHOULD continue to try to reconnect infrequently (e.g., approximately 
every 3600 seconds). 


3.6.3. State Mismatch 


In the states indicated by "-" in Table 14in Appendix A, user action is required to reset the 
association state or to recover it, for example, from backup storage. In those cases, the server 
sends the error code 2002 to the peer. If possible, both the EAP server and peer SHOULD indicate 
this error condition to the user or server administrator. 
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3.6.4. Negotiation Failure 


If there is no matching protocol version, the peer sends the error code 3001 to the server. If there is 
no matching cryptosuite, the peer sends the error code 3002 to the server. If there is no matching 
OOB direction, the peer sends the error code 3003 to the server. 


In practice, there is no way of recovering from these errors without software or hardware 
changes. If possible, both the EAP server and peer SHOULD indicate these error conditions to the 
user. 


3.6.5. Cryptographic Verification Failure 


If the receiver of the OOB message detects an unrecognized Peerld or incorrect fingerprint 
(Hoob) in the OOB message, the receiver MUST remain in the Waiting for OOB (1) state as if no 
OOB message was received. The receiver SHOULD indicate the failure to accept the OOB message 
to the user. No in-band error message is sent. 


Note that if the OOB message was delivered from the server to the peer and the peer does not 
recognize the Peerld, the likely cause is that the user has unintentionally delivered the OOB 
message to the wrong peer device. If possible, the peer SHOULD indicate this to the user; however, 
the peer device may not have the capability for many different error indications to the user, and 
it MAY use the same indication as in the case of an incorrect fingerprint. 


The rationale for the above is that the invalid OOB message could have been presented to the 
receiver by mistake or intentionally by a malicious party; thus, it should be ignored in the hope 
that the honest user will soon deliver a correct OOB message. 


If the EAP server or peer detects an incorrect message authentication code (MACs, MACp, MACs2, 
or MACp2), it sends the error code 4001 to the other side. As specified in the beginning of Section 
3.6, the failed Completion Exchange will not result in server or peer state changes, while an error 
in the Reconnect Exchange will put both sides to the Reconnecting (3) state and thus lead to 
another reconnect attempt. 


The rationale for this is that the invalid cryptographic message may have been spoofed by a 
malicious party; thus, it should be ignored. In particular, a spoofed message on the in-band 
channel should not force the honest user to perform the OOB Step again. In practice, however, the 
error may be caused by other failures, such as a software bug. For this reason, the EAP server MAY 
limit the rate of peer connections with SleepTime after the above error. Also, there SHOULD be a 
way for the user to reset the peer to the Unregistered (0) state so that the OOB Step can be 
repeated as the last resort. 


3.6.6. Application-Specific Failure 


Applications MAY define new error messages for failures that are specific to the application or to 
one type of OOB channel. They MAY also use the generic application-specific error code 5001 or 
the error codes 5002 and 5004, which have been reserved for indicating invalid data in the 
ServerInfo and PeerInfo fields, respectively. Additionally, anticipating OOB channels that make 
use of a URL, the error code 5003 has been reserved for indicating an invalid server URL. 
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4. ServerInfo and PeerInfo Contents 


The ServerInfo and PeerInfo fields in the Initial Exchange and Reconnect Exchange enable the 
server and peer, respectively, to send information about themselves to the other endpoint. They 
contain JSON objects whose structure may be specified separately for each application and each 
type of OOB channel. ServerInfo and PeerInfo MAY contain auxiliary data needed for the OOB 
channel messaging and for EAP channel binding (see Section 6.7). This section describes the 
optional initial data fields for ServerInfo and PeerInfo registered by this specification. Further 
specifications may request new application-specific ServerInfo and PeerInfo data fields from 
IANA (see Sections 5.4 and 5.5). 


Data Field 


Type 


ServerName 


ServerURL 


SSIDList 


Base64SSID List 


Description 


Type-tag string that can be used by the peer as a hint for how to interpret 
the ServerInfo contents. 


String that may be used to aid human identification of the server. 


Prefix string when the OOB message is formatted as a URL, as suggested in 
Appendix D. 


List of IEEE 802.11 wireless network service set identifier (SSID) strings used 
for roaming support, as suggested in Appendix C. JSON array of ASCII- 
encoded SSID strings. 


List of IEEE 802.11 wireless network identifier (SSID) strings used for 
roaming support, as suggested in Appendix C. JSON array of SSIDs, each of 
which is base64url-encoded without padding. Peers SHOULD send at most 
one of the fields SSIDList and Base64SSIDList in PeerInfo, and the server 
SHOULD ignore SSIDList if Base64SSIDList is included. 


Table 6: ServerInfo Data Fields 


Data Field 


Type 


PeerName 
Manufacturer 
Model 


SerialNumber 


Aura, et al. 


Description 


Type-tag string that can be used by the server as a hint for how to interpret 
the PeerInfo contents. 


String that may be used to aid human identification of the peer. 
Manufacturer or brand string. 
Manufacturer-specified model string. 


Manufacturer-assigned serial number. 
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Data Field Description 


MACAddress Peer link-layer 48-bit extended unique identifier (EUI-48) in the 12-digit 
base-16 form [EUI-48]. The string MAY be in upper or lower case and MAY 
include additional colon ':' or dash '-' characters that MUST be ignored by the 
server. 


SSID IEEE 802.11 network SSID for channel binding. The SSID is an ASCII string. 


Base64SSID IEEE 802.11 network SSID for channel binding. The SSID is base64url 
encoded. Peer SHOULD send at most one of the fields SSID and Base64SSID in 
PeerInfo, and the server SHOULD ignore SSID if Base64SSID is included. 


BSSID Wireless network basic service set identifier (BSSID) (EUI-48) in the 12-digit 
base-16 form [EUI-48] for channel binding. The string MAY be in upper or 
lower case and MAY include additional colon ':' or dash '-' characters that 
MUST be ignored by the server. 


Table 7: PeerInfo Data Fields 


5. IANA Considerations 


This section provides information regarding registration of values related to the EAP-NOOB 
method, in accordance with [RFC8126]. 


The EAP Method Type for EAP-NOOB (value 56) has been assigned in the "Method Types" 
subregistry of the "Extensible Authentication Protocol (EAP) Registry”. 


Per this memo, IANA has created and will maintain a new registry entitled "Nimble Out-of-Band 
Authentication for EAP Parameters (EAP-NOOB)" in the Extensible Authentication Protocol (EAP) 
category. Also, IANA has created and will maintain the subregistries defined in the following 
subsections. 


5.1. Cryptosuites 


IANA has created and will maintain a new subregistry entitled "EAP-NOOB Cryptosuites" in the 
"Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry. Cryptosuites are 
identified by an integer. Each cryptosuite MUST specify an ECDHE curve for the key exchange, 
encoding of the ECDHE public key as a JWK object, and a cryptographic hash function for the 
fingerprint and HMAC computation and key derivation. The hash value output by the 
cryptographic hash function MUST be at least 32 bytes in length. The initial values for this registry 
are: 


Cryptosuite Algorithms 


0 Reserved 
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Cryptosuite Algorithms 


1 ECDHE curve Curve25519 [RFC7748], public-key format [RFC7517], hash 
function SHA-256 [RFC6234]. The JWK encoding of Curve25519 public key is 
defined in [RFC8037]. For clarity, the "crv" parameter is "X25519", the "kty" 
parameter is "OKP", and the public-key encoding contains only an x- 
coordinate. 


2 ECDHE curve NIST P-256 [FIPS186-4], public-key format [RFC7517], hash 
function SHA-256 [RFC6234]. The JWK encoding of NIST P-256 public key is 
defined in [RFC7518]. For clarity, the "crv" parameter is "P-256", the "kty" 
parameter is "EC", and the public-key encoding has both an x and y 
coordinate, as defined in Section 6.2.1 of [RFC7518]. 


Table 8: EAP-NOOB Cryptosuites 


EAP-NOOB implementations MUST support Cryptosuite 1. Support for Cryptosuite 2 is 
RECOMMENDED. An example of a Cryptosuite 1 public-key encoded as a JWK object is given below. 
(Line breaks are for readability only.) 


"jwk":{"kty":"OKP", "crv" :"X25519", "x" :"3p7bfXt9wbTTW2HC70Q1Nz- 
DQ8hbeGdNrfx-FG-IK@8" } 


Assignment of new values for new cryptosuites MUST be done through IANA with "Specification 
Required", as defined in [RFC8126]. 


5.2. Message Types 


IANA has created and will maintain a new subregistry entitled "EAP-NOOB Message Types" in the 
"Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry. EAP-NOOB 
request and response pairs are identified by an integer Message Type. The initial values for this 
registry are: 


Message Used in Purpose 

Type Exchange 

0 Error Error notification 

1 All exchanges Peerld and PeerState discovery 

2 Initial Version, cryptosuite, and parameter negotiation 

3 Initial Exchange of ECDHE keys and nonces 

4 Waiting Indication to the peer that the server has not yet received 


an OOB message 
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Message Used in Purpose 

Type Exchange 

5 Completion Noobld discovery 

6 Completion Authentication and key confirmation with HMAC 
7 Reconnect Version, cryptosuite, and parameter negotiation 
8 Reconnect Exchange of ECDHE keys and nonces 

9 Reconnect Authentication and key confirmation with HMAC 


Table 9: EAP-NOOB Message Types 


Assignment of new values for new Message Types MUST be done through IANA with "Specification 
Required", as defined in [RFC8126]. 


5.3. Error Codes 


IANA has created and will maintain a new subregistry entitled "EAP-NOOB Error codes" in the 
"Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry. Cryptosuites are 
identified by an integer. The initial values for this registry are: 


Errorcode Purpose 


1001 Invalid NAI 

1002 Invalid message structure 

1003 Invalid data 

1004 Unexpected message type 

1005 Invalid ECDHE key 

2001 Unwanted peer 

2002 State mismatch, user action required 
2003 Unrecognized OOB message identifier 
2004 Unexpected peer identifier 

3001 No mutually supported protocol version 
3002 No mutually supported cryptosuite 
3003 No mutually supported OOB direction 
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Errorcode Purpose 


4001 HMAC verification failure 

5001 Application-specific error 

5002 Invalid server info 

5003 Invalid server URL 

5004 Invalid peer info 

6001-6999 Reserved for Private and Experimental Use 


Table 10: EAP-NOOB Error Codes 


Assignment of new error codes MUST be done through IANA with "Specification Required", as 
defined in [RFC8126], except for the range 6001-6999. This range is reserved for "Private Use" and 
"Experimental Use", both locally and on the open Internet. 


5.4. ServerInfo Data Fields 


IANA has created and will maintain a new subregistry entitled "EAP-NOOB ServerInfo Data 
Fields" in the "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry. The 
initial values for this registry are: 


Data Field Specification 

Type RFC 9140, Section 4 
ServerName RFC 9140, Section 4 
ServerURL RFC 9140, Section 4 
SSIDList RFC 9140, Section 4 


Base64SSIDList RFC 9140, Section 4 
Table 11: ServerInfo Data Fields 


Assignment of new values for new ServerInfo data fields MUST be done through IANA with 
"Specification Required", as defined in [RFC8126]. 


5.5. PeerInfo Data Fields 


IANA is requested to create and maintain a new subregistry entitled "EAP-NOOB PeerInfo Data 
Fields" in the "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry. The 
initial values for this registry are: 
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Data Field Specification 
Type RFC 9140, Section 4 
PeerName RFC 9140, Section 4 


Manufacturer RFC 9140, Section 4 
Model RFC 9140, Section 4 


SerialNumber RFC 9140, Section 4 


MACAddress RFC 9140, Section 4 
SSID RFC 9140, Section 4 
Base64SSID RFC 9140, Section 4 
BSSID RFC 9140, Section 4 


Table 12: PeerInfo Data Fields 


Assignment of new values for new PeerInfo data fields MUST be done through IANA with 
"Specification Required", as defined in [RFC8126]. 


5.6. Domain Name Reservation 


The special-use domain "eap-noob.arpa" has been registered in the .arpa registry (https:// 
www.iana.org/domains/arpa) and the "Special-Use Domain Names" registry (https:// 
www.iana.org/assignments/special-use-domain-names). 


5.7. Guidance for Designated Experts 


Experts SHOULD be conservative in the allocation of new Cryptosuites. Experts MUST ascertain 
that the requested values match the current Crypto Forum Research Group (CFRG) guidance on 
cryptographic algorithm security. Experts MUST ensure that any new Cryptosuites fully specify the 
encoding of the ECDHE public key and should include details, such as the value of the "kty" (key 
type) parameter when JWK[RFC7517] encoding is used. 


Experts SHOULD be conservative in the allocation of new Message Types. Experts SHOULD 
ascertain that a well-defined specification for the new Message Type is permanently and publicly 
available. 


Experts SHOULD be conservative in the allocation of new Error codes, since the 6001-6999 range is 
already reserved for private and experimental use. 
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Experts MAY be liberal in the allocation of new ServerInfo and PeerInfo data fields. Experts MUST 
ensure that the data field requested has a unique name that is not easily confused with existing 
registrations. For example, requests for a new PeerInfo data field "ssid" should be rejected even 
though it is unique because it can be confused with the existing registration of "SSID". Experts 
MUST ensure that a suitable Description for the data field is available. 


6. Security Considerations 


EAP-NOOB is an authentication and key derivation protocol; thus, security considerations can be 
found in most sections of this specification. In the following, we explain the protocol design and 
highlight some other special considerations. 


6.1. Authentication Principle 


EAP-NOOB establishes a shared secret with an authenticated ECDHE key exchange. The mutual 
authentication in EAP-NOOB is based on two separate features, both conveyed in the OOB 
message. The first authentication feature is the secret nonce Noob. The peer and server use this 
secret in the Completion Exchange to mutually authenticate the session key previously created 
with ECDHE. The message authentication codes computed with the secret nonce Noob are alone 
sufficient for authenticating the key exchange. The second authentication feature is the integrity- 
protecting fingerprint Hoob. Its purpose is to prevent impersonation attacks even in situations 
where the attacker is able to eavesdrop on the OOB channel and the nonce Noob is compromised. 
In some human-assisted OOB channels, such as human-perceptible audio or a user-typed URL, it 
may be easier to detect tampering than disclosure of the OOB message, and such applications 
benefit from the second authentication feature. 


The additional security provided by the cryptographic fingerprint Hoob is somewhat intricate to 
understand. The endpoint that receives the OOB message uses Hoob to verify the integrity of the 
ECDHE exchange. Thus, the OOB receiver can detect impersonation attacks that may have 
happened on the in-band channel. The other endpoint, however, is not equally protected because 
the OOB message and fingerprint are sent only in one direction. Some protection to the OOB 
sender is afforded by the fact that the user may notice the failure of the association at the OOB 
receiver and therefore reset the OOB sender. Other device-pairing protocols have solved similar 
situations by requiring the user to confirm to the OOB sender that the association was accepted 
by the OOB receiver, e.g., with a button press on the sender side. Applications MAY implement EAP- 
NOOB in this way. Nevertheless, since EAP-NOOB was designed to work with strictly one- 
directional OOB communication and the fingerprint is only the second authentication feature, 
the EAP-NOOB specification does not mandate such explicit confirmation to the OOB sender. 


To summarize, EAP-NOOB uses the combined protection of the secret nonce Noob and the 
cryptographic fingerprint Hoob, both conveyed in the OOB message. The secret nonce Noob 
alone is sufficient for mutual authentication unless the attacker can eavesdrop on it from the 
OOB channel. Even if an attacker is able to eavesdrop on the secret nonce Noob, it nevertheless 
cannot perform a full impersonation attack on the in-band channel because a mismatching 
fingerprint would alert the OOB receiver, which would reject the OOB message. The attacker that 
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eavesdropped on the secret nonce can impersonate the OOB receiver to the OOB sender. If it does, 
the association will appear to be complete only on the OOB sender side, and such situations have 
to be resolved by the user by resetting the OOB sender to the initial state. 


The expected use cases for EAP-NOOB are ones where it replaces a user-entered access credential 
in IoT appliances. In wireless network access without EAP the user-entered credential is often a 
passphrase that is shared by all the network stations. The advantage of an EAP-based solution, 
including EAP-NOOB, is that it establishes a different shared secret for each peer device, which 
makes the system more resilient against device compromise. Another advantage is that it is 
possible to revoke the security association for an individual device on the server side. 


Forward secrecy during fast reconnect in EAP-NOOB is optional. The Reconnect Exchange in EAP- 
NOOB provides forward secrecy only if both the server and peer send their fresh ECDHE keys. This 
allows both the server and peer to limit the frequency of the costly computation that is required 
for forward secrecy. The server MAY adjust the frequency of its attempts at ECDHE rekeying based 
on what it knows about the peer's computational capabilities. 


Another way in which some servers may control their computational load is to reuse the same 
ECDHE key for all peers over a short server-specific time window. In that case, forward secrecy 
will be achieved only after the server updates its ECDHE key, which may be a reasonable trade-off 
between security and performance. However, the server MUST NOT reuse the same ECDHE key 
with the same peer when rekeying with ECDHE (KeyingMode=2 or KeyingMode=3). Instead, it can 
simply not send an ECDHE key (KeyingMode=1). 


The users delivering the OOB messages will often authenticate themselves to the EAP server, e.g., 
by logging into a secure web page or API. In this case, the server can associate the peer device with 
the user account. Applications that make use of EAP-NOOB can use this information for 
configuring the initial owner of the freshly registered device. 


6.2. Identifying Correct Endpoints 


Potential weaknesses in EAP-NOOB arise from the fact that the user must physically identify the 
correct peer device. If the user mistakenly delivers the OOB message from the wrong peer device 
to the server, the server may create an association with the wrong peer. The reliance on the user 
in identifying the correct endpoints is an inherent property of user-assisted, out-of-band 
authentication. To understand the potential consequences of the user mistake, we need to 
consider a few different scenarios. In the first scenario, there is no malicious party, and the user 
makes an accidental mistake between two out-of-the-box devices that are both ready to be 
registered to a server. If the user delivers the OOB message from the wrong device to the server, 
confusion may arise but usually no security issues. In the second scenario, an attacker 
intentionally tricks the user, for example, by substituting the original peer device witha 
compromised one. This is essentially a supply chain attack where the user accepts a 
compromised physical device. 


There is also a third scenario, in which an opportunistic attacker tries to take advantage of the 
user's accidental mistake. For example, the user could play an audio or a blinking LED message to 
a device that is not expecting to receive it. In simple security bootstrapping solutions that 
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transfer a primary key to the device via the OOB channel, the device could misuse or leak the 
accidentally received primary key. EAP-NOOB is not vulnerable to such opportunistic attackers 
because the OOB message has no value to anyone who did not take part in the corresponding 
Initial Exchange. 


One mechanism that can mitigate user mistakes is certification of peer devices. A certificate or 
an attestation token (e.g., [TLS-CWT] and [RATS-EAT]) can convey to the server authentic 
identifiers and attributes, such as model and serial number, of the peer device. Compared to a 
fully certificate-based authentication, however, EAP-NOOB can be used without trusted third 
parties and does not require the user to know any identifier of the peer device; physical access to 
the device is sufficient for bootstrapping with EAP-NOOB. 


Similarly, the attacker can try to trick the user into delivering the OOB message to the wrong 
server so that the peer device becomes associated with the wrong server. If the EAP server is 
accessed through a web user interface, the attack is akin to phishing attacks where the user is 
tricked into accessing the wrong URL and wrong web page. OOB implementation witha 
dedicated app on a mobile device, which communicates witha server API at a preconfigured URL, 
can protect against such attacks. 


After the device registration, an attacker could clone the device identity by copying the keys from 
the persistent EAP-NOOB association into another device. The attacker can be an outsider who 
gains access to the keys or the device owner who wants to have two devices matching the same 
registration. The cloning threats can be mitigated by creating the cryptographic keys and storing 
the persistent EAP-NOOB association on the peer device in a secure hardware component such as 
a trusted execution environment (TEE). Furthermore, remote attestation on the application level 
could provide assurance to the server that the device has not been cloned. Reconnect Exchange 
with a new cryptosuite (KeyingMode=3) will also disconnect all but the first clone that performs 
the update. 


6.3. Trusted Path Issues and Mishbinding Attacks 


Another potential threat is spoofed user input or output on the peer device. When the user is 
delivering the OOB message to or from the correct peer device, a trusted path between the user 
and the peer device is needed. That is, the user must communicate directly with an authentic 
operating system and EAP-NOOB implementation in the peer device and not with a spoofed user 
interface. Otherwise, a registered device that is under the control of the attacker could emulate 
the behavior of an unregistered device. The secure path can be implemented, for example, by 
having the user press a reset button to return the device to the Unregistered (0) state and to 
invoke a trusted UI. The problem with such trusted paths is that they are not standardized across 
devices. 


Another potential consequence of a spoofed UI is the misbinding attack where the user tries to 
register a correct but compromised device, which tricks the user into registering another 
(uncompromised) device instead. For example, the compromised device might have a malicious, 
full-screen app running, which presents to the user QR codes copied, in real time, from another 
device's screen. If the unwitting user scans the QR code and delivers the OOB message in it to the 
server, the wrong device may become registered in the server. Such misbinding vulnerabilities 
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arise because the user does not have any secure way of verifying that the in-band cryptographic 
handshake and the out-of-band physical access are terminated at the same physical device. Sethi 
et al. [Sethi19] analyze the misbinding threat against device-pairing protocols and also EAP- 
NOOB. Essentially, all protocols where the authentication relies on the user's physical access to 
the device are vulnerable to misbinding, including EAP-NOOB. 


A standardized trusted path for communicating directly with the trusted computing base ina 
physical device would mitigate the misbinding threat, but such paths rarely exist in practice. 
Careful asset tracking on the server side can also prevent most misbinding attacks if the peer 
device sends its identifiers or attributes in the PeerInfo field and the server compares them with 
the expected values. The wrong but uncompromised device's PeerInfo will not match the 
expected values. Device certification by the manufacturer can further strengthen the asset 
tracking. 


6.4. Peer Identifiers and Attributes 


The Peerld value in the protocol is a server-allocated identifier for its association with the peer 
and SHOULD NOT be shown to the user because its value is initially ephemeral. Since the Peerld is 
allocated by the server and the scope of the identifier is the single server, the so-called identifier 
squatting attacks, where a malicious peer could reserve another peer's identifier, are not possible 
in EAP-NOOB. The server SHOULD assign a random or pseudorandom Peerld to each new peer. It 
SHOULD NOT select the PeerlId based on any peer characteristics that it may know, suchas the 
peer's link-layer network address. 


User reset or failure in the OOB Step can cause the peer to perform many Initial Exchanges with 
the server, which allocates many Peerld values and stores the ephemeral protocol state for them. 
The peer will typically only remember the latest ones. EAP-NOOB leaves it to the implementation 
to decide when to delete these ephemeral associations. There is no security reason to delete them 
early, and the server does not have any way to verify that the peers are actually the same one. 
Thus, it is safest to store the ephemeral states on the server for at least one day. If the OOB 
messages are sent only in the server-to-peer direction, the server SHOULD NOT delete the 
ephemeral state before all the related Noob values have expired. 


After completion of EAP-NOOB, the server may store the PeerInfo data, and the user may use it to 
identify the peer and its attributes, such as the make and model or serial number. A compromised 
peer could lie in the PeerInfo that it sends to the server. If the server stores any information about 
the peer, it is important that this information is approved by the user during or after the OOB 
Step. Without verification by the user or authentication on the application level, the PeerInfo is 
not authenticated information and should not be relied on. One possible use for the PeerInfo field 
is EAP channel binding (see Section 6.7). 


6.5. Downgrading Threats 


The fingerprint Hoob protects all the information exchanged in the Initial Exchange, including 
the cryptosuite negotiation. The message authentication codes MACs and MACp also protect the 
same information. The message authentication codes MACs2 and MACp2 protect information 
exchanged during key renegotiation in the Reconnect Exchange. This prevents downgrading 
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attacks to weaker cryptosuites, as long as the possible attacks take more time than the maximum 
time allowed for the EAP-NOOB completion. This is typically the case for recently discovered 
cryptanalytic attacks. 


As an additional precaution, the EAP server and peer MUST check for downgrading attacks in the 
Reconnect Exchange as follows. As long as the server or peer saves any information about the 
other endpoint, it MUST also remember the previously negotiated cryptosuite and MUST NOT 
accept renegotiation of any cryptosuite that is known to be weaker than the previous one, such as 
a deprecated cryptosuite. Determining the relative strength of the cryptosuites is out of scope of 
this specification and may be managed by implementations or by local policies at the peer and 
server. 


Integrity of the direction negotiation cannot be verified in the same way as the integrity of the 
cryptosuite negotiation. That is, if the OOB channel used in an application is critically insecure in 
one direction, an on-path attacker could modify the negotiation messages and thereby cause that 
direction to be used. Applications that support OOB messages in both directions SHOULD, 
therefore, ensure that the OOB channel has sufficiently strong security in both directions. While 
this is a theoretical vulnerability, it could arise in practice if EAP-NOOB is deployed in new 
applications. Currently, we expect most peer devices to support only one OOB direction; in which 
case, interfering with the direction negotiation can only prevent the completion of the protocol. 


The long-term shared key material Kz in the persistent EAP-NOOB association is established with 
an ECDHE key exchange when the peer and server are first associated. It isa weaker secret thana 
manually configured random shared key because advances in cryptanalysis against the used 
ECDHE curve could eventually enable the attacker to recover Kz. EAP-NOOB protects against such 
attacks by allowing cryptosuite upgrades in the Reconnect Exchange and by updating the shared 
key material Kz whenever the cryptosuite is upgraded. We do not expect the cryptosuite upgrades 
to be frequent, but, if an upgrade becomes necessary, it can be done without manual reset and 
reassociation of the peer devices. 


6.6. Protected Success and Failure Indications 


Section 7.16 of [RFC3748] allows EAP methods to specify protected result indications because EAP- 
Success and EAP-Failure packets are neither acknowledged nor integrity protected. [RFC3748] 
notes that these indications may be explicit or implicit. 


EAP-NOOB relies on implicit, protected success indicators in the Completion Exchange and 
Reconnect Exchange. Successful verification of MACs and MACs2 in the EAP-Request message 
from the server (message type 6 and message type 9, respectively) acts as an implicit, protected 
success indication to the peer. Similarly, successful verification of MACp and MACp2 in the EAP- 
Response message from the peer (message type 6 and message type 9, respectively) act as an 
implicit, protected success indication to the server. 
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EAP-NOOB failure messages are not protected. Protected failure result indications would not 
significantly improve availability since EAP-NOOB reacts to most malformed data by ending the 
current EAP conversation in EAP-Failure. However, since EAP-NOOB spans multiple 
conversations, failure in one conversation usually means no state change on the level of the EAP- 
NOOB state machine. 


6.7. Channel Binding 


EAP channel binding, defined in [RFC6677], means that the endpoints compare their perceptions 
of network properties, such as lower-layer identifiers, over the secure channel established by EAP 
authentication. Section 4.1 of [RFC6677] defines two approaches to channel binding. EAP-NOOB 
follows the first approach, in which the peer and server exchange plaintext information about the 
network over a channel that is integrity protected with keys derived during the EAP execution. 
More specifically, channel information is exchanged in the plaintext PeerInfo and ServerInfo 
objects and is later verified with message authentication codes (MACp, MACs, MACp2, and 
MACs2). This allows policy-based comparison with locally perceived network properties on either 
side, as well as logging for debugging purposes. The peer MAY include in PeerInfo any data items 
that it wants to bind to the EAP-NOOB association and to the exported keys. These can be 
properties of the authenticator or the access link, such as the SSID and BSSID of the wireless 
network (see Table 6). As noted in Section 4.3 of [RFC6677], the scope of the channel binding varies 
between deployments. For example, the server may have less link-layer information available 
from roaming networks than from a local enterprise network, and it may be unable to verify all 
the network properties received in PeerInfo. There are also privacy considerations related to 
exchanging the ServerInfo and PeerInfo while roaming (see Section 6.10). 


Channel binding to secure channels, defined in [RFC5056], binds authentication at a higher 
protocol layer to a secure channel at a lower layer. Like most EAP methods, EAP-NOOB exports 
the session keys MSK and EMSK, and an outer tunnel or a higher-layer protocol can bind its 
authentication to these keys. Additionally, EAP-NOOB exports the key AMSK, which may be used 
to bind application-layer authentication to the secure channel created by EAP-NOOB and to the 
session keys MSK and EMSK. 


6.8. Denial of Service 


While denial-of-service (DoS) attacks by on-link attackers cannot be fully prevented, the design 
goal in EAP-NOOB is to void long-lasting failure caused by an attacker who is present only 
temporarily or intermittently. The main defense mechanism is the persistent EAP-NOOB 
association, which is never deleted automatically due to in-band messages or error indications. 
Thus, the endpoints can always use the persistent association for reconnecting after the DoS 
attacker leaves the network. In this sense, the persistent association serves the same function in 
EAP-NOOB as a permanent primary key or certificate in other authentication protocols. We 
discuss logical attacks against the updates of the persistent association in Section 6.9. 


In addition to logical DoS attacks, it is necessary to consider resource exhaustion attacks against 
the EAP server. The number of persistent EAP-NOOB associations created in the server is limited 
by the need for a user to assist in delivering the OOB message. The users can be authenticated for 
the input or output of the OOB message at the EAP server, and any users who create excessive 
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numbers of persistent associations can be held accountable and their associations can be deleted 
by the server administrator. What the attacker can do without user authentication is to perform 
the Initial Exchange repeatedly and create a large number of ephemeral associations (server in 
Waiting for OOB (1) state) without ever delivering the OOB message. In Section 6.4, it was 
suggested that the server should store the ephemeral states for at least a day. This may require off- 
loading the state storage from memory to disk during a DoS attack. However, if the server 
implementation is unable to keep up witha rate of Initial Exchanges performed by a DoS 
attacker and needs to drop some ephemeral states, no damage is caused to already-created 
persistent associations, and the honest users can resume registering new peers when the DoS 
attacker leaves the network. 


There are some trade-offs in the protocol design between politely backing off and giving way to 
DoS attackers. An on-link DoS attacker could spoof the SleepTime value in the Initial Exchange or 
Waiting Exchange to cause denial of service against a specific peer device. There is an upper limit 
on the SleepTime (3600 seconds) to mitigate the spoofing threat. This means that, in the presence 
of an on-link DoS attacker who spoofs the SleepTime, it could take up to one hour after the 
delivery of the OOB message before the device performs the Completion Exchange and becomes 
functional. Similarly, the Unwanted peer error (error code 2001) could cause the peer to stop 
connecting to the network. If the peer device is able to alert the user about the error condition, it 
can safely stop connecting to the server and wait for the user to trigger a reconnection attempt, 
e.g., by resetting the device. As mentioned in Section 3.6.2, peer devices that are unable to alert the 
user should continue to retry the Initial Exchange infrequently to avoid a permanent DoS 
condition. We believe a maximum backoff time of 3600 seconds is reasonable for a new protocol 
because malfunctioning or misconfigured peer implementations are at least as great a concern 
as DoS attacks, and politely backing off within some reasonable limits will increase the 
acceptance of the protocol. The maximum backoff times could be updated to be shorter as the 
protocol implementations mature. 


6.9. Recovery from Loss of Last Message 


The EAP-NOOB Completion Exchange, as well as the Reconnect Exchange with cryptosuite update, 
results in a persistent state change that should take place either on both endpoints or on neither; 
otherwise, the result is a state mismatch that requires user action to resolve. The state mismatch 
can occur if the final EAP response of the exchanges is lost. In the Completion Exchange, the loss 
of the final response (Type=6) results in the peer moving to the Registered (4) state and creating a 
persistent EAP-NOOB association while the server stays in an ephemeral state (1 or 2). In the 
Reconnect Exchange, the loss of the final response (Type=9) results in the peer moving to the 
Registered (4) state and updating its persistent key material Kz while the server stays in the 
Reconnecting (3) state and keeps the old key material. 


The state mismatch is an example of an unavoidable problem in distributed systems: it is 
theoretically impossible to guarantee synchronous state changes in endpoints that communicate 
asynchronously. The protocol will always have one critical message that may get lost, so that one 
side commits to the state change and the other side does not. In EAP, the critical message is the 
final response from the peer to the server. While the final response is normally followed by EAP- 
Success, [RFC3748], Section 4.2 states that the peer MAY assume that the EAP-Success was lost and 
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the authentication was successful. Furthermore, EAP method implementations in the peer do not 
receive notification of the EAP-Success message from the parent EAP state machine [RFC4137]. 
For these reasons, EAP-NOOB on the peer side commits to a state change already when it sends 
the final response. 


The best available solution to the loss of the critical message is to keep trying. EAP retransmission 
behavior defined in Section 4.3 of [RFC3748] suggests 3-5 retransmissions. In the absence of an 
attacker, this would be sufficient to reduce the probability of failure to an acceptable level. 
However, a determined attacker on the in-band channel can drop the final EAP-Response 
message and all subsequent retransmissions. In the Completion Exchange (KeyingMode=0) and 
Reconnect Exchange with cryptosuite upgrade (KeyingMode=3), this could result in a state 
mismatch and persistent denial of service until the user resets the peer state. 


EAP-NOOB implements its own recovery mechanism that allows unlimited retries of the 
Reconnect Exchange. When the DoS attacker eventually stops dropping packets on the in-band 
channel, the protocol will recover. The logic for this recovery mechanism is specified in Section 
3.4.2. 


EAP-NOOB does not implement the same kind of retry mechanism in the Completion Exchange. 
The reason is that there is always a user involved in the initial association process, and the user 
can repeat the OOB Step to complete the association after the DoS attacker has left. On the other 
hand, Reconnect Exchange needs to work without user involvement. 


6.10. Privacy Considerations 


There are privacy considerations related to performing the Reconnect Exchange while roaming. 
The peer and server may send updated PeerInfo and ServerInfo fields in the Reconnect Exchange. 
This data is sent unencrypted between the peer and the EAP authenticator, such as a wireless 
access point. Thus, it can be observed by both outsiders and the access network. The PeerInfo field 
contains identifiers and other information about the peer device (see Table 6). While the 
information refers to the peer device and not directly to the user, it can leak information about 
the user to the access network and to outside observers. The ServerInfo, on the other hanad, can 
leak information about the peer's affiliation with the home network. For this reason, the optional 
PeerInfo and ServerInfo in the Reconnect Exchange SHOULD be omitted unless some critical data 
has changed and it cannot be updated on the application layer. 


Peer devices that randomize their Layer 2 address to prevent tracking can do this whenever the 
user resets the EAP-NOOB association. During the lifetime of the association, the Peerld is a 
unique identifier that can be used to track the peer in the access network. Later versions of this 
specification may consider updating the PeerlId at each Reconnect Exchange. In that case, it is 
necessary to consider how the authenticator and access-network administrators can recognize 
and add misbehaving peer devices to a deny list, as well as how to avoid loss of synchronization 
between the server and the peer if messages are lost during the identifier update. 
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To enable stronger identity protection in later versions of EAP-NOOB, the optional server- 
assigned NAI (NewNAI) SHOULD have a constant username part. The RECOMMENDED username is 
"noob". The server MAY, however, send a different username in NewNAI to avoid username 
collisions within its realm or to conform to a local policy on usernames. 


6.11. EAP Security Claims 
EAP security claims are defined in Section 7.2.1 of [RFC3748]. The security claims for EAP-NOOB 


are listed in Table 13. 


Security Property 


Authentication 
mechanism 


Protected cryptosuite 
negotiation 


Mutual authentication 
Integrity protection 
Replay protection 
Confidentiality 

Key derivation 

Key strength 


Dictionary attack 
protection 


Fast reconnect 
Cryptographic binding 
Session independence 
Fragmentation 


Channel binding 


EAP-NOOB Claim 


ECDHE key exchange with out-of-band authentication 


yes 


yes 
yes 
yes 
no 

yes 


The specified cryptosuites provide key strength of at least 128 bits. 


yes 


yes 
not applicable 
yes 
no 


yes (The ServerInfo and PeerInfo can be used to convey integrity- 
protected channel properties, such as network SSID or peer MAC 
address.) 


Table 13: EAP Security Claims 
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Appendix A. Exchanges and Events per State 


Table 14 shows how the EAP server chooses the exchange type depending on the server and peer 


nn 


states. In the state combinations marked with hyphen "-", there is no possible exchange and user 
action is required to make progress. Note that peer state 4is omitted from the table because the 
peer never connects to the server when the peer is in that state. The table also shows the handling 
of errors in each exchange. A notable detail is that the recipient of error code 2003 moves to state 
1; 


Peer States Exchange Chosen by the Server Next Peer and Server States 
Server State: Unregistered (0) 

0..2 Initial Exchange both 1 (0 on error) 

3 - no change, notify user 


Server State: Waiting for OOB (1) 


0 Initial Exchange both 1 (0 on error) 
1 Waiting Exchange both 1 (no change on error) 
2 Completion Exchange both 4 (A) 
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Peer States Exchange Chosen by the Server Next Peer and Server States 
3 - no change, notify user 


Server State: OOB Received (2) 


0 Initial Exchange both 1 (0 on error) 

1 Completion Exchange both 4 (B) 

2 Completion Exchange both 4 (A) 

3 - no change, notify user 


Server State: Reconnecting (3) or Registered (4) 
0..2 - no change, notify user 


3 Reconnect Exchange both 4 (3 on error) 


Table 14: How the Server Chooses the Exchange Type 


(A) peer to 1 on error 2003; no other changes on error 


(B) server to 1 on error 2003; no other changes on error 


Table 15 lists the local events that can take place in the server or peer. Both the server and peer 
output and accept OOB messages in association state 1, leading the receiver to state 2. 
Communication errors and timeouts in states 0..2 lead back to state 0, while similar errors in 
states 3..4 lead to state 3. An application request for rekeying (e.g., to refresh session keys or to 
upgrade cryptosuite) also takes the association from state 3..4 to state 3. The user can always reset 
the association state to 0. Recovering association data, e.g., from a backup, leads to state 3. 


Server/Peer State Possible Local Events inthe Server and Peer Next State 


il OOB Output il 
1 OOB Input 2 (1 on error) 
022 Mobility/timeout/network failure 0 
3..4 Mobility/timeout/network failure 3 
3..4 Rekeying request 3 
0..4 User resets association 0 
0..4 Association state recovery 3 


Table 15: Local Events in the Server and Peer 
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Appendix B. Application-Specific Parameters 


Table 16 lists OOB channel parameters that need to be specified in each application that makes 
use of EAP-NOOB. The list is not exhaustive and is included for the convenience of implementers 
only. 


Parameter Description 
OobDirs Allowed directions of the OOB channel. 
OobMessageEncoding Howthe OOB message data fields are encoded for the OOB channel. 


SleepTimeDefault Default minimum time in seconds that the peer should sleep before 
the next Waiting Exchange. 


OobRetries Number of received OOB messages with invalid Hoob, after which 
the receiver moves to Unregistered (0) state. When the OOB channel 
has error detection or correction, the RECOMMENDED value is 5. 


NoobTimeout How many seconds the sender of the OOB message remembers the 
sent Noob value. The RECOMMENDED value is 3600 seconds. 


ServerInfoType The value of the Type field and the other required fields in 
ServerInfo. 
PeerInfoType The value of the Type field and the other required fields in PeerInfo. 


Table 16: OOB Channel Characteristics 


Appendix C. EAP-NOOB Roaming 


AAA architectures [RFC2904] allow for roaming of network-connected appliances that are 
authenticated over EAP. While the peer is roaming in a visited network, authentication still takes 
place between the peer and an authentication server at its home network. EAP-NOOB supports 
such roaming by allowing the server to assign a NAI to the peer. After the NAI has been assigned, it 
enables the visited network to route the EAP session to the peer's home AAA server. 


A peer device that is new or has gone through a hard reset should be connected first to the home 
network and establish an EAP-NOOB association with its home AAA server before it is able to 
roam. After that, it can perform the Reconnect Exchange from the visited network. 


Alternatively, the device may provide some method for the user to configure the NAI of the home 
network. This is the user or application-configured NAI mentioned in Section 3.3.1. In that case, 
the EAP-NOOB association can be created while roaming. The configured NAI enables the EAP 
messages to be routed correctly to the home AAA server. 
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While roaming, the device needs to identify the networks where the EAP-NOOB association can be 
used to gain network access. For 802.11 access networks, the server MAY send a list of SSID strings 
in the ServerInfo field, called either SSIDList or Base64SSIDList. The list is formatted as explained 
in Table 6. If present, the peer MAY use this list as a hint to determine the networks where the EAP- 
NOOB association can be used for access authorization, in addition to the access network where 
the Initial Exchange took place. 


Appendix D. OOB Message as a URL 


While EAP-NOOB does not mandate any particular OOB communication channel, typical OOB 
channels include graphical displays and emulated NFC tags. In the peer-to-server direction, it may 
be convenient to encode the OOB message as a URL, which is then encoded as a QR code for 
displays and printers or as an NFC Data Exchange Format (NDEF) record for dynamic NFC tags. A 
user can then simply scan the QR code or NFC tag and open the URL, which causes the OOB 
message to be delivered to the authentication server. The URL MUST specify https or another 
server-authenticated scheme so that there is a secure connection to the server and the on-path 
attacker cannot read or modify the OOB message. 


The ServerInfo in this case includes a field called ServerURL of the following format witha 
RECOMMENDED length of at most 60 characters: 


https://<host>[:<port>]/[<path>] 


To this, the peer appends the OOB message fields (PeerId, Noob, and Hoob) as a query string. 
Peerld is provided to the peer by the server and might be a 22-character ASCII string. The peer 
base64url encodes, without padding, the 16-byte values Noob and Hoob into 22-character ASCII 
strings. The query parameters MAY be in any order. The resulting URL is of the following format: 


https://<host>[:<port>]/[<path>]?P=<PeerId>&N=<Noob>&H=<Hoob> 


The following is an example of a well-formed URL encoding the OOB message (without line 
breaks): 


https://aaa.example.com/eapnoob?P=mcm5BSCDZ45cYP1Ar1ghNw&N=rMinS@- 
FAEfCU8D91jxX_A&H=QvnMp4UGxuQVFaXPW_14UW 
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